Posts

Post not yet marked as solved
3 Replies
Content steering should be available in Safari when playing HLS via the native video element. If you're using an MSE-based HLS player you'll need to implement Content Steering yourself.
Post not yet marked as solved
1 Replies
Sounds like a bad video bitstream. The iOS video decoder is pickier in some ways about incorrect video encodes. If you can, you should find a video bitstream analyzer and run your video through it.
Post not yet marked as solved
1 Replies
Please file a bug, including test content.
Post not yet marked as solved
1 Replies
I'm not aware of any standard headers that every AirPlay receiver (Apple and/or third-party) guarantee to supply. One approach you might investigate is to supply your authentication token as a query parameter in the Multivariant Playlist (manifest) URL. That should carry across to the AirPlay receiver.
Post not yet marked as solved
1 Replies
Sure. Just create a Multivariant Playlist with one or more tiers (EXT-X-STREAM-INF) whose playlists contain audio-only segments. Use EXT-X-MEDIA tags to create a group of renditions, one per language. There are various WWDC talks that cover this, such as https://developer.apple.com/videos/play/wwdc2020/10225/
Post not yet marked as solved
1 Replies
Interstitials should be fetched after the primary content has been buffered to the interstitial point. If you're not seeing that, please file a bug with a sample app + content.
Post not yet marked as solved
3 Replies
There's a good chance that there are one or more problems with the way that you're encrypting your content, and that's triggering decode errors on the Apple TV. If you look at the console log on the device, it may be reporting these decode errors. It would be a good idea to follow the instructions here to verify the validity of your streams: https://developer.apple.com/library/archive/technotes/tn2454/_index.html
Post not yet marked as solved
2 Replies
Arg, sorry, answered the question in the wrong window. To answer your question, I would expect the HLS player to make concurrent requests for audio and video segments. I would not expect it to issue concurrent requests for successive segments, as later segments will delay earlier segments due to competition for the download bandwidth. It's a reasonable optimization to make concurrent requests for the MAP segment and the first Media Segment (although it would only save you a single RTT). Please file an enhancement request if you'd like us to consider that.
Post not yet marked as solved
2 Replies
MobileVlcKit isn't provided by Apple. Have you tried asking the videolan folks?
Post not yet marked as solved
3 Replies
I think you should file a bug if you have a case where AVPlayerItem.duration remains indefinite after loading the playlist containing an EXT-X-ENDLIST tag. Don't forget to install the CoreMedia (HTTP Live Streaming) logging profile from the Profiles and Logs page and grab a sysdiagnose to attach to your bug after reproducing it. Note that if there are separate playlists for audio or subtitles that they should contain EXT-X-ENDLIST tags as well.
Post not yet marked as solved
3 Replies
If you have missing content from your contribution feed, the best approach is to fill the missing regions with dummy segments that are marked with the EXT-X-GAP tag. This will tell the player to avoid those regions of those bitrates (switching down if it has to) or playing silence / no video if it cannot avoid them, until it reaches non-gap segments again. EXT-X-GAP tags do not have to be aligns across renditions.
Post not yet marked as solved
2 Replies
I don't think that this is an issue that has been reported before this. Please file a bug at https://feedbackassistant.apple.com including instructions to reproduce and sample media so that we can look into it.
Post not yet marked as solved
19 Replies
Yes, the same limitation exists with any media segment (TS, fmp4, packed audio, WebVTT, whatever). You should write a bug describing your use case to ask for AVPictureInPictureController support in AVSampleBufferDisplayLayer. Until you get that you can look into using LL-HLS vended from an HTTP server running on the device. HLS isn't really suited to low-latency applications but LL-HLS is much better. Note that there's no particular reason that a web server needs to hit the disk. At the end of the day it's just an application that is listening on a TCP port and responding to HTTP GET requests.